IMO we should choose a lane for param generation:

1. either use rand(r) and the _randUint method to generate all parameters
2. or allow forge to generate all parameters and if we need additional randomness, use cheats.randomUint and similar

#1 means we should do sequential runs, supplying (1, 2, 3, 4, etc)
#2 means we just let forge decide and we only control the number of runs

Or I guess there's a way to do both - let forge generate parameters via #2, but run tests using forge t --fuzz-seed <1, 2, 3, ...>

That may be most convenient?

I prefer option #2 but open to either. My impression was we eventually want to give Foundry some more direction (e.g. slash from initialMaxMag 1 to WAD - 1), but I believe we discussed that as a parallel, second route which we would do in addition to letting Foundry fire whatever inputs it feels like

IMO number of slashes doesn't really impact the "path" so much as it defines the depth you're testing to (and overall runtime). I think this should not be a random param, but something we define.

I actually think it's valuable to randomize within a bound! I've just found a test where 500 slashes does not show precision loss by the end of the test, but 1 slash does.

I suggest we either do one of two things:

1. Keep # of slashes as parameterized value (easy, more simple)
2. Measure more granular precision loss after every operation (hard, more granular)

We can measure it how we like, but I suggest we keep slashing as a parametrized value until we have more sophisticated intermediate measurements for precision loss in the file. So we can do option 1 until option 2 is ready.

Here's a point we may want to change - we're allocating all available magnitude before we use multiple slashes to "get funds out".

It kinda makes sense that this wouldn't result in any loss.

What if we don't allocate all available magnitude here, and instead allocate a portion of it (parameterized). We then use multiple slashes to get a portion of the funds out via redistribution, and then attempt to withdraw remaining funds via queue+completeWithdrawals?

Maybe this is captured in partialMagsSlashed? not sure.

partialMagsSlashed somewhat does this. It allocates all magnitude but doesn't fully slash at the end, leaving some partial residual magnitude. We can def add another test case that partially allocates.

I kinda want to refactor this a bit to more explicitly set the parameter we're trying to set here -- we're using this method to "set max magnitude", not "initialWadToSlash"